RHACM

RHACM allows you to manage many Kubernetes clusters from a single location. While the concept of a stretch cluster is something that is often requested, the complexity and potential problems that come with it due to conditions that are beyond the cluster’s control—such as network latencies—usually outweigh the perceived benefits. The preferred approach is multiple clusters—which can be large or small—that are centrally managed. Red Hat Advanced Cluster Management provides this functionality and more.

Within the RHACM web console, there are four main sections that you use to manage different aspects of your Kubernetes clusters and workloads.

Your hub cluster only does one thing—it runs RHACM. All of the RHACM components that provide functionality for the Cluster Lifecycle, Application Lifecycle, and Governance, Risk, and Compliance (GRC) features run on this cluster. Your hub cluster cannot be managed. If you were to try to add the hub cluster as a managed cluster, you would see an error message and that action would be prevented. Do not attempt this.

Your managed cluster also does one thing—it runs your workloads. Customer application workloads are obviously going to run here, but managed clusters also run the RHACM endpoint components. These endpoint components are deployed as Pods and scheduled to run on nodes in the cluster just as any other application would.

RHACM employs a pull-based architectural model that relies on an agent in the cluster joining an external management plane. This architecture has emerged across the Kubernetes and GitOps ecosystem, and it is where Red Hat has focused its upstream and product investments. The endpoint that you deploy onto the managed cluster communicates with RHACM running on the hub cluster.

While a managed cluster can be either OpenShift or another flavor of Kubernetes, the hub cluster can only be deployed on OpenShift. In this lab, both clusters are deployed in a supported cloud provider. The cloud provider may be different depending on when and where you are doing this lab. This does not really matter because everything in the cloud provider that you need is abstracted for you by OpenShift.

Your clusters are slightly different in size. Each one has three master nodes to provide a highly available control plane. Your hub cluster has three workers, while your managed cluster only has two. This is due to the resources required by the RHACM components and can be further tuned. For instance, by using larger worker instances, the number of worker nodes could be decreased in quantity.

To begin, it is important to define exactly what GRC is. In RHACM, you build policies that are applied to managed clusters. These policies can do different things, which are described below, but they ultimately serve to govern the configurations of your clusters. This governance over your cluster configurations reduces risk and ensures compliance with standards defined by stakeholders, which can include security teams and operations teams.

This table describes the three types of policy controllers available in RHACM along with the remediation mode they support: